Skip to main content
Version: 24.03

part_policies

Policies​

Access Policies​

Access policies like the BPN access policy are described in the policy section of the Industry Core KIT.

Usage Policies / Contract Policies​

It is recommended to restrict the data usage for all traceability aspects. An example of one usage policy containing three different constraints is shown and described in the following:

{
  "@context": {
    "odrl": "http://www.w3.org/ns/odrl/2/"
  },
  "@type": "PolicyDefinitionRequestDto",
  "@id": "<POLICY-ID>", // Important for the contract definition
  "policy": {
    "@type": "Policy",
    "odrl:permission": [
      {
        "odrl:action": "USE",
        "odrl:constraint": {
          "@type": "LogicalConstraint",
          "odrl:and": [ // All of the following three constraints have to be fullfilled (and, not or)
            // First constraint to verify the the Catena-X membership
            {
              "@type": "Constraint",
              "odrl:leftOperand": "Membership",
              "odrl:operator": {
                "@id": "odrl:eq"
              },
              "odrl:rightOperand": "active"
            },
            // Second constraint to verify if the framework agreement for the traceability use case is accepted
            {
              "@type": "Constraint",
              "odrl:leftOperand": "FrameworkAgreement.traceability",
              "odrl:operator": {
                "@id": "odrl:eq"
              },
              "odrl:rightOperand": "active"
            },
            // Third constraint to define the specific purpose, further detailed in the framework agreement
            {
              "@type": "Constraint",
              "odrl:leftOperand": "PURPOSE",
              "odrl:operator": {
                "@id": "odrl:eq"
              },
              "odrl:rightOperand": "<POSSIBLE-PURPOSE-STRING>" // See list in the framework agreement
            }
          ]
        }
      }
    ]
  }
}

✋ Standardization Keep in mind that the odrl:leftOperand and the odrl:rightOperand will be standardized. Therefore, check the latest JSON payload after every release if it is still up-to-date. Otherwise, data sharing might not be possible if the policies are wrong.

Membership Policy​

To verify the participants Catena-X membership, the Membership verifiable credential can be used. In case of a policy, the data can only be used from verified Catena-X members. The payload is shown in the first constraint-part of the example above and described in detail in the EDC part of the SSI documentation.

{
  "@type": "Constraint",
  "odrl:leftOperand": "Membership",
  "odrl:operator": {
    "@id": "odrl:eq"
  },
  "odrl:rightOperand": "active"
}

Framework Agreement Policy​

To verify if a participant accepted the framework agreement of a specific use case created by the Catena-X association, the FrameworkAgreement.traceability verifiable credential can be used for the traceability framework agreement. Further details and the framework agreement itself can be downloaded from the Governance Framework for Data Space Operations. In case of a policy, the data can only be used from accepted and verified traceability framework agreement members. This is shown in the second constraint-part of the example above and described in detail in the EDC part of the SSI documentation.

{
  "@type": "Constraint",
  "odrl:leftOperand": "FrameworkAgreement.traceability",
  "odrl:operator": {
    "@id": "odrl:eq"
  },
  "odrl:rightOperand": "active"
}

Purpose-based Policy​

To further restrict the data usage, a purpose-based policy can be used. If, for example, the purpose mentions a quality investigation, this means that the data usage is only allowed for handling and working on the quality investigation. All possible purposes and their meanings are defined in the traceability framework agreement. This allows to create a uniform understanding and a standardized set of payloads in the network by connecting technical strings to legal agreements.

It is highly recommended to only use this purpose-based policy together with the Framework Agreement Policy. Only with both together it can be ensured that the payload of the purpose policy is agreed by the other part and is based on the same set.

Details about the endpoint and payload can be found in the Transfer Data sample in the tractus-x EDC repository.

{
  "@type": "Constraint",
  "odrl:leftOperand": "PURPOSE",
  "odrl:operator": {
    "@id": "odrl:eq"
  },
  "odrl:rightOperand": "<POSSIBLE-PURPOSE-STRING>"
}

The <POSSIBLE-PURPOSE-STRING> have to be replaced with one purpose string defined in the traceability framework agreement.

Individual Agreements and Contracts​

There might be some individual agreements and contracts between two companies. It is possible to reference such a bilateral contract with the purpose-based policy. In this case, the odrl:rightOperand includes the unique reference to the contract. It is planned to standardize the format in future upcoming releases.

Contract Definitions​

In a last step, these policies need to be connected to the data by a contract definition (see Transfer Data sample in the tractus-x EDC repository for further details). When using an Access Policy, their id needs to be included as a value of the accessPolicyId key in the contract definition. When using an above-mentioned Usage Policy, their id needs to be included as a value of the contractPolicyId key in the contract definition.